上篇粗淺講了DevOps的角色衝突與QA在DevOps實踐中的定位

這篇就來聊聊一些QA實際能做的DevOps日常

Recap上篇的結論，QA最重要的工作就在「穿針引線」的持續溝通。

可能只是隨口問一句migration加進release SOP了沒

或是收到客戶的feature request後，有沒有把開發時間排入下個release內

這些都有幫助，但總有些不錯的Best Practice，以下是可以考慮的方向

自動化金字塔

講到敏捷跟DevOps，絕對少不了系列文章前幾篇提到的自動化

除了把繁瑣重複性的工作讓程式去做驗證之外

由於持續且快速的迭代性質，加上CI/CD的引入，RD從Unit test做自動化

到QA開始負責API automation到Feature integration + UI automation

都是為了快速的修改與部署而準備。

試想如果一天上三個新版本，QA不可能無時無刻都幫每個build跑回歸測試

這個時候就是依賴著測試金字塔建構的test case去跑完最重要的User Scenario

自動build code，自動跑API testing，自動deployment，一不小心就能上線？

這個階段也是QA比較接近Dev的時刻，工作內容比較偏測試左移

需要相當了解產品功能與使用情境，也要很緊密跟開發團隊合作，

並依照這些使用情境去編寫對應的自動化程式。

系統監控與遙測資料（Monitoring & Telemetry）

這點在軟體產業裡面也是一個得天獨厚的優勢，以常見的client-server架構

SaaS伺服器上的資料都是我們可以做資料分析的來源，加上客戶端資料的收集

藉由像是EFK(Elasticsearch, Fluentd, Kibana)的Log蒐集開源服務

搭配上Graphite + Grafana 這類的Time-series的資料庫加儀表板系統

可以作出老闆很喜歡的Dashboard，讓我們更理解真實環境上軟體產品的運行狀態。

這也是QA比較接近Ops的時刻，工作內容也比較偏測試右移

需要很了解產品放到真實世界中究竟會發生什麼事情

並建構出不管產品遇到什麼緊急狀況，都有辦法查到問題並快速修復的高復原力。

而上述的解決方案也都是測試右移上常見的實踐，我會在後面的章節詳細描述。

自身經驗分享

我自己在QA旅程中是兩邊都有做過，沒有好壞之分，但前者很吃產品的功能

產品功能會影響到你寫自動化的深度與可以學習到的東西

後者比較像是去學習一個現行可運行的架構，不論是資料處理或是資料分析

藉由不同的業務需求可以去提出不同的解決方案

而且這些學習到的技能通用性較高，比較能帶著走，也是我覺得更有動力的部分。

可能也是個性使然，我比較喜歡讓自己測試的東西到正式客戶環境去闖江湖

比較不喜歡一直在測試環境裡面驗證一些可能不會發生的corner case

但我的意思不是說驗證這件事情不重要，而是要驗證有意義的東西XD

所以在工作中接觸到測試右移相關的實踐之後，也陸續朝著跟客戶服務端靠攏

雖然接到P0, P1 case很刺激，有時候有SLA的時間壓力也蠻大

但整個工作內容多了不少的變化，思考的角度可以從Dev出發，也可以從Ops出發，

最重要的是可以看到軟體開發不同角度的生態，這點就讓我在接下來篇章慢慢分享。

下篇來分享接客戶report issue，比較有趣的經驗們